Check if this issue is valid — if so, understand the root cause and fix it. At lib/attio/isRecordInList.ts, line 16:

<comment>An Attio membership-read failure is treated as “not in the list,” so `upsertValuationLead` proceeds to `addRecordToList` and can create duplicate pipeline cards during an Attio outage or malformed response. Returning a separate verification error (or otherwise making the caller skip the add when the read cannot be trusted) would preserve deduplication.</comment>

<file context>
@@ -0,0 +1,20 @@
+  const res = await attioFetch(`/objects/${object}/records/${recordId}/entries`, {
+    method: "GET",
+  });
+  if (!res.ok) return false;
+  const data = await res.json().catch(() => null);
+  const entries: Array<{ list_id?: string; id?: { list_id?: string } }> = data?.data ?? [];
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/attio/request.ts, line 9:

<comment>A network rejection from Attio escapes the low-level helper and aborts the lead flow before its Telegram alert, despite the wrappers and `upsertValuationLead` promising best-effort behavior. Handling fetch rejections in the helper or each operation wrapper would let the flow log the Attio failure and continue.</comment>

<file context>
@@ -0,0 +1,17 @@
+ * Reads ATTIO_API_KEY at call time (server-only); returns the raw Response.
+ */
+export function attioFetch(path: string, init?: RequestInit): Promise<Response> {
+  return fetch(`${ATTIO_BASE_URL}${path}`, {
+    ...init,
+    headers: {
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/valuation/captureValuationLead.ts, line 55:

<comment>A transient Attio network failure suppresses the Telegram alert, despite this flow requiring the alert to continue after Attio errors. Catch a rejected `upsertValuationLead` locally and convert it to the existing failed outcome before sending.</comment>

<file context>
@@ -0,0 +1,73 @@
+
+    // Attio is the system of record. Don't block the ping on an Attio error —
+    // the valuation already succeeded — but log a dropped lead so it's observable.
+    const attio = await upsertValuationLead(lead);
+    if (!attio.success) {
+      console.error("[valuation/lead] Attio enrichment failed:", attio.error);
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/attio/isRecordInList.ts, line 13:

<comment>A transient fetch rejection currently escapes despite this helper's best-effort contract, so lead capture can reject instead of treating the membership lookup as absent. Catch request/response parsing failures and validate `data.data` before calling `.some()`.</comment>

<file context>
@@ -0,0 +1,20 @@
+  recordId: string,
+  listId: string,
+): Promise<boolean> {
+  const res = await attioFetch(`/objects/${object}/records/${recordId}/entries`, {
+    method: "GET",
+  });
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/valuation/upsertValuationLead.ts, line 40:

<comment>When `assertPersonByEmail` returns a 200 OK response but the JSON body is missing `data.data.id.record_id`, `recordId` is `undefined`. The `return { success: true }` on the `!recordId` path means the code reports success without creating a note, adding a pipeline card, or logging anything — effectively dropping the lead silently.

The JSON-parsing catch in `assertPersonByEmail` (`res.json().catch(() => null)`) means this path is reachable whenever the Attio API returns a 200 with an unexpected or malformed body. While unlikely, this is the one path where a lead can be lost without observability.</comment>

<file context>
@@ -0,0 +1,59 @@
+  const today = new Date().toISOString().slice(0, 10);
+  const { recordId, error } = await assertPersonByEmail(leadAttributes(lead, today));
+  if (error) return { success: false, error };
+  if (!recordId) return { success: true };
+
+  const recordUrl = `https://app.attio.com/${ATTIO_WORKSPACE}/person/${recordId}/overview`;
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/attio/request.ts, line 8:

<comment>This Attio request helper is exported as `attioFetch` but lives in `request.ts`, which breaks the repository's required function-to-file naming convention. Moving it to `lib/attio/attioFetch.ts` keeps imports and module discovery consistent.</comment>

<file context>
@@ -0,0 +1,17 @@
+ * operation module (assertPersonByEmail, createNote, …) stays a thin wrapper.
+ * Reads ATTIO_API_KEY at call time (server-only); returns the raw Response.
+ */
+export function attioFetch(path: string, init?: RequestInit): Promise<Response> {
+  return fetch(`${ATTIO_BASE_URL}${path}`, {
+    ...init,
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/attio/__tests__/addRecordToList.test.ts, line 33:

<comment>A failed assertion in this test can leak the `console.error` spy into later tests because `mockRestore()` is only reached on the success path. Moving spy cleanup into an `afterEach`/`finally` path would preserve test isolation.</comment>

<file context>
@@ -0,0 +1,35 @@
+      addRecordToList("valuation_leads", "people", "rec_1", { stage: ["New"] }),
+    ).resolves.toBeUndefined();
+    expect(errSpy).toHaveBeenCalled();
+    errSpy.mockRestore();
+  });
+});
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/attio/__tests__/createNote.test.ts, line 37:

<comment>Spy on `console.error` is restored inline in the test body but not in `afterEach`, so a test failure before the restore line leaves the spy active across tests. Move restoration into `afterEach` so it runs regardless of pass/fail.</comment>

<file context>
@@ -0,0 +1,42 @@
+
+  it("logs but does not throw on failure", async () => {
+    vi.stubGlobal("fetch", vi.fn().mockResolvedValue(new Response("bad", { status: 500 })));
+    const errSpy = vi.spyOn(console, "error").mockImplementation(() => {});
+    await expect(createNote(note)).resolves.toBeUndefined();
+    expect(errSpy).toHaveBeenCalled();
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At lib/format/usd.ts, line 7:

<comment>`NaN` and `±Infinity` pass through to produce `"$NaN"`, `"$∞"`, and `"$-∞"` — none of which are valid USD strings. A guard at the top of the function would make the contract defensive against unexpected inputs.</comment>

<file context>
@@ -0,0 +1,9 @@
+ * from `lib/emails/valuationReport/formatCompactUsd` (which compacts to "$54.6M"
+ * for the email) and `lib/stripe/formatUsd` (which takes cents, for billing).
+ */
+export function usd(n: number): string {
+  return `$${Math.round(n).toLocaleString("en-US")}`;
+}
</file context>